Read Bend 2 code, with a rule for its laws - #31

…or size unsent

A law whose first answer stays undecided is asked a Choice naming what
its comment says beyond the law: nothing, context, a property, more
inputs or a consequence under an unstated condition.

A request the provider refuses as beyond the model's context no longer
fails its file: the units it asked that no other request answered need
context, as units the budget does not send.

…generalizes

Of 29 laws still undecided after the relation Choice on thirteen Bend 2
projects, 11 checked one fixed key, an empty or one-entry object or one
byte under a comment claiming the behavior in general. Asked directly, the
4 at 0.65 or more were all right.

…ling benchmarks apart

A comment above a law also describes the laws right after it that have
no comment of their own: "sound and complete" heads nfa_sound and
nfa_complete. Copies in sibling benchmark programs, such as bendlang/bend's
bench/runtime/*, are not compared, as sibling examples are not.

Hardcoded values: a case pattern's literal is not a candidate (Bend
matches only literals and constructors), a Bool predicate that laws
check and the defs only it calls hold samples, and the kind follow-up
offers a bound that only needs to be large enough and an arbitrary
mixing constant, and names a one-line def made to name its value.

Function questions: the split note states Bend's shapes (one def per
state machine, helper defs for computed matches, proofs following their
definition), and flattening proposes nested patterns and a case _
fallback instead of guard clauses and early returns.

On thirteen Bend 2 projects, labeled by hand: function-simplification
findings from 24 right and 16 wrong to 19 and 3; hardcoded-value
considers from 59 right and 144 wrong to 58 and 65.

A Bend 2 test is a whole program pinned to the output its run prints; the
4 shared-logic findings between two such tests on thirteen Bend 2
projects were all wrong.

A proof's steps follow the cases of what it proves, and its copies the
rewrites each constructor needs, or a lemma a standalone demo or eval
repeats. On 25 Bend 2 projects, the 4 function-simplification and 3
shared-logic findings on proofs were all wrong; a proof is a def of a
PROOF.bend, one that fills a law, or one that returns an equality.

A Bend 2 test is a whole program, so a file on a test path that defines
main is one test, whether its expected output ends the file or sits
beside it, as bendc's tests/X.out. Asked their purpose, 48 of 85 such
files stayed unresolved and were judged as application code, and a law
of bendc's compiler feature test became a review.

A section's opening paragraph, above a blank line, speaks of the
section's laws together: bulkhead's, which draws a restart claim from
several laws, was read as the promise of the first one below it.

Bend 2 writes each match arm, binding and effect on a line of its own.
On 25 Bend 2 projects, the 16 file-organization findings on files of
fewer member lines were all labeled wrong, and the 13 right ones were on
files of 313 member lines or more. The floor is min_bend_file_lines in
the decision policy.

Function simplification and shared logic leave Bend 2 proofs out and
word their questions for Bend 2; shared logic keeps sibling benchmarks
and separate Bend 2 tests apart; file organization weighs a Bend 2 file
only past its own floor; hardcoded values asks Bend 2 what kind of value
it is.

The laws example was nfa_sound, whose comment also heads nfa_complete; it
is body_after_blank of the HTTP client demo, whose law checks only texts
that open with the blank line.

A PROOF.bend, a file named after what it proves (padding_proof.bend,
BloomSafeProof.bend) or one under a proof or proofs directory holds
proofs: its defs are not asked to be split nor about values, and its
laws are lemmas whose comments say how a proof goes. On the 16 projects
where such files were first judged, 12 of 14 function-simplification
findings in them were wrong and the rest debatable, as were 14 of 15 law
findings, and 36 of 40 hardcoded-value findings were wrong.

In a library of proofs, a derivation written out in several lemmas is
one a shared lemma would serve: on the 16 projects where proofs were
first compared, 32 of 41 shared-logic findings on files of proofs were
right and 5 wrong. The three wrong ones this was tuned on were a lemma
repeated in a standalone demo and an eval, and case arms of one proof.
Function simplification still leaves proofs out: its 16 findings on
them across 41 projects were all wrong (2 more debatable).

A benchmark's values are its workload: the sizes, seeds and ranges its C
or TypeScript twin shares and its expected output pins. Of 82
hardcoded-value findings in the benchmark directories of Bend 2 projects,
70 were wrong.

An author who rules a Bend 2 file off into sections (# ----, # === Title)
has laid it out as one module in parts, and the groups proposed from its
calls rarely follow them: on 41 Bend 2 projects, 7 of 43 file-organization
findings on files with two or more section rules were right, against 10
of 17 on files without.

Bend 2 writes each match arm, binding and effect on a line of its own
and runs to long files, which the split question reads as several
modules. On 64 Bend 2 projects, 14 of 43 file-organization reviews were
right: 8 of 13 on the 41 the floor and sections were tuned on, and 6 of
30 on 23 projects never used for tuning.

Measured on 41 Bend 2 projects used for tuning and 23 never used for it,
with every review and a sample of considers labeled by hand.

JevGate's own review of this branch read law_predicates as mixing
separate jobs: collecting what laws and tests call, keeping the Bool
predicates only other predicates call, and adding the defs only they
call. Each step is its own function now; behavior is unchanged.